IBIS Macromodel Task Group Meeting date: 27 February 2024 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora System: * Dian Yang Raj Raghuram Cadence Design Systems: * Ambrish Varma Jared James Dassault Systemes: Longfei Bai Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak * Kinger Cai Chi-te Chen Liwei Zhao Alaeddin Aydiner Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: Chulsoon Hwang Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Siemens EDA (Mentor): * Arpad Muranyi * Randy Wolff Teraspeed Labs: Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that the meeting scheduled for February 20th had not been held because of limited attendee availability. ------------- Review of ARs: Michael: Develop a new clarification BIRD to more clearly define relationships between concepts, terms, and parameters such as block, block size, wave_size, etc. - Done. Michael sent draft2 to the ATM list on February 20th. Michael: Send draft3 of BIRD229.1 to the IBIS Open Forum as an official BIRD. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the February 13th meeting. Ambrish moved to approve the minutes. Michael seconded the motion. There were no objections. -------------- New Discussion: AMI Block Concepts Clarification BIRD: Michael reviewed draft2 of the proposed BIRD. He noted that the BIRD now also contains some clarifications related to time units. He said this was not because the time unit concepts are directly related to the block concepts, but he had noticed that as IBIS 7.2 was drafted we reorganized the specification in such a way that certain terms, e.g., 'NRZ', were not defined until after they had already been used. In addition, he had observed that the term "time segment" had been used for a block concept since the earliest days of AMI. Michael said that the BIRD modifies 8 sections of the specification. He noted that three sections (pgs. 291, 295, 299) use identical language in step-by-step flow descriptions, and the modifications to these sections are identical. On page 216, in the time domain simulation flow description, the first usage of "time segments" (i.e., blocks) appears. The section gives an example describing the length of the simulated waveform in terms of "bits", which implies NRZ, and Michael suggested that we make that explicit or instead use the term "symbols". Arpad noted that the example describes breaking a one million bit waveform into 1000 segments of 1000 bits each. The text then states: The segments are not required to be equally sized and are not required to contain an integer number of bits. Arpad wondered whether it would be helpful to have the example illustrate this point. Michael recalled his question about BCI_Message_Interval_UI from the last meeting. He said it seems reasonable that the value of this parameter must be at least 1, but this is not stated. Ambrish noted that BCI_Message_Interval_UI is not a required parameter, but he agreed that its value should be non-zero if it is provided. However, Ambrish said there was already language offering guidance on this in Other Notes: The model maker/protocol designer should choose a value of BCI_Message_Interval_UI that is slightly larger than the smallest number of training UI required per adaptation. Ambrish said he thought it wasn't worth pursuing any clarification in this area unless someone could demonstrate a problem. Michael said that he thought this should be a separate BIRD if it were ever pursued. Arpad asked everyone to review Michael's clarification BIRD. Arpad said that while he agreed with the intent of the BIRD, he found its language changes somewhat overbearing and hard to read smoothly. Michael said one alternative was to introduce a "definitions" section in the specification. He said that having a definitions section would free up the rest of the text and allow it to flow more smoothly. Michael took an AR to review draft2 with the goal of streamlining the language. Arpad said he would send Michael his suggestions privately. Providing placeholder values for non-string AMI parameters: Arpad noted that DC_Offset is an AMI Reserved parameter for which the value specified in the .ami file is merely a placeholder. The EDA tool is responsible for providing the correct value when it calls AMI_Init. Arpad said it raised the question of whether there was a way (for non-string parameters) to make it clear that the value given in the .ami file is merely a placeholder. Randy said that confusion can sometimes arise when users see a value in the .ami file and aren't immediately sure it's a placeholder. Randy said that nothing is actually broken or incorrect, but some users had been confused when reading the DC_Offset parameter definition in the specification. Ambrish and Curtis asked whether any change to add an official "placeholder" value was really necessary. They pointed out that the Usage Rules for DC_Offset already state: The EDA tool ignores the DC_Offset value specified in the .ami file. In addition, the DC_Offset Example's Description string's value is: "The EDA tool is responsible for determining the input value sent to the executable model." Ambrish and Curtis suggested that we could simply add "The value in the .ami file is ignored." to the Description string in the example. This should make it clear to the reader. Curtis and Ambrish said this would make it a simple editorial BIRD. Model makers could use the same approach in their .ami files. Arpad asked whether the group agreed with this approach. There were no objections. Arpad took an AR to draft an editorial clarification BIRD. Randy asked about Reserved AMI parameters of Usage Out. Ambrish cited PAM_Thresholds and PAM_Offsets as two examples. They are of Type String (the string's value contains a list of one or more numbers). The group reviewed the Example for PAM_Thresholds, which contains: (Value "0.00 0.00 0.00") Arpad suggested that since PAM_Thresholds is of Type String, the Value should just be "placeholder". Ambrish said it had been "placeholder" in draft7 of IBIS7.2, and Randy confirmed that was true. Randy said the final version of IBIS7.2 had reverted to the "0.00 0.00 0.00" value used in draft6. Ambrish and Curtis said they understood the desire to use "placeholder" for consistency, but they argued that having the list of dummy values in the Example was helpful and provided an example of the expected syntax. Arpad said the "0.00 0.00 0.00" could be problematic. He said he'd seen examples of models that did not return PAM_Thresholds in their AMI_parameters_out, and the dummy values in the .ami file were mistakenly used by the tool and stopped the tool from computing the thresholds itself. Ambrish and Curtis said that was a problem caused by a bad model. The model is required to return a value for PAM_Thresholds (if it appears in the .ami file), as it's only of Usage Out. Arpad said this "simple" clarification BIRD was becoming more complicated. Proposal for a new [Clock Group] keyword: Michael said he would begin work on this proposal shortly. He asked people to email him if they have thoughts on the topic. He said he'll be working on a [Clock Group] keyword to define the relationships between pins in [Clock Pins]. He said the problem is that these grouping relationships may be fixed for some device architectures, but they might be configurable for other device architectures. - Ambrish: Motion to adjourn. - Michael: Second. - Arpad: Thank you all for joining. New ARs: Michael: Review draft2 of the Block Concepts Clarification BIRD and attempt to streamline the language. Arpad: Draft an editorial clarification BIRD to make it clearer to the reader when an AMI parameter's value in the .ami file is merely a placeholder. ------------- Next meeting: 05 March 2024 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives